Okay, you've put a lot of time into your program and you're ready to share it with the world! Right? Well, maybe. Before you release your program, make sure it is the best it can be. We're not talking about the structure or look of the code. We're talking about the application, from the user's point of view.
Excellence
"If you want to achieve excellence, you can get there today. As of this second, quit doing less-than-excellent work." - Thomas Watson, Founder of IBM
How does it look?
Does your program look professional? Are the controls spaced well? Are the controls sized correctly - neither too large, nor too small? Are they crowded together? Is there too much empty space on the window? Now is the time to tweak the GUI so that it looks really good! This is the time to check your spelling!
Consider your target audience!
If you create a program window that is 1000 pixels wide, it won't work on displays that are 800 or 640 pixels wide. If you want to appeal to the widest audience, keep your window size small, or use the DisplayWidth and DisplayHeight to set the size of the window, and the size and placement of controls.
A word about colors.
Liberty BASIC gives you the ability to use the named colors to color windows and controls. Use this ability sparingly. Users set up a desktop color scheme that pleases them. Honor that. Don't force your users to try to read red text on a black background! There are places where the use of colors in the GUI are helpful, but in general, oddly colored applications are a sure sign of a novice programmer!
Is it easy to use?
Think of end user - make it easy. Use standard methods and interfaces. You might think it looks cute to have a popup window with no titlebar or X-close button, but with an EXIT button on the lower left, but it will be frustrating to your users. We are used to closing windows by clicking on a button in the upper right corner.
Make the GUI intuitive. The user should be able to use the features of your program just by looking at the window. Use labels freely.
HELP!
Even though you have an intuitive GUI, don't forget to provide instructions. A standard help file works very well, but requires a compiler. If the instructions are brief, they can be given in a simple NOTICE. If they are longer, they can be printed in a text window. You can easily write a simple HTML file in a text editor. You can also use onw of Tom Nally's native Liberty BASIC help systems. Try Bitmap Help - A Simple Help Engine in this issue, or "LB Simple Help" which can be found here: [http://babek.info/libertybasicfiles/lbnews/nl120/lsh2.htm]
For terrific guidance on writing help systems, see the article by Jerry Muelver in issue #105, "Help is on the Way." [http://babek.info/libertybasicfiles/lbnews/nl105/WikiWriter.htm]
You should also use an "about" box. This is usually a simple NOTICE message stating the name of the author of the progam, along with copyright information and credits.
Picky, picky, picky!
Did you include hot keys for all menus and menu items? Indicate hot keys by placing an ampersand & in front of the letter that will be the hot key. The user can then hit the ALT key, followed by the hot key to open the menu.
Give some guidance!
Fill in default values in prompts, textboxes, etc. Cause a default item to be selected in listbox or combobox. Be sure to select a default button in group of radiobuttons and check default checkboxes. The user should not be confronted with a lot of empty boxes when he starts the program. If he likes the defaults, he can leave them. If he wants to make changes, he can see the default values and use them to guide him in making selections.
Don't allow errors!
Error trapping is very important. If your program crashes, users are not likely to try it again. They might even shy away from future programs written by you.
Be sure to trap the close event. In the closing branch label, close all opened devices such as windows, files and DLLs. When you run the program from within the Liberty BASIC IDE, if the program ends without closing all opened handles, Liberty BASIC gives you an error message. Make note of these errors and fix them. When the program runs from the runtime engine, it will simply crash, perhaps corrupting data.
Allow the user to cancel actions without errors. If he chooses to open a file, then cancels the filedialog, your program should trap that error. If the user cancels, the return variable will be an empty string. If the program tries to open a non-existent file, it will crash. Trap that possibility easily, like this:
filedialog "Open","*.txt",file$ if file$="" then wait open file$ for input as #f 'more code follows...
Your program has no way of knowing how much data is in a file, so you cannot use a simple FOR/NEXT loop with INPUT or LINE INPUT. The program will halt with an error if it attempts to read past the end of the file. Use EOF in a WHILE/WEND to loop through files and get input.
open file$ for input as #f
while EOF(#f) = 0 'while the end of file has not been reached
input #f, item$
print item$
wend
You can determine the number of characters (the length) of a file with the LOF function.
fileLength = LOF(#f)
Test, test, test!
It's all fine and dandy for you to test your own program, but you know what it is supposed to do! Before releasing a program, have several other people test it. This will insure that it works properly on different operating systems. It will also tell you whether you've missed some things that can cause the program to crash, or to give unexpected results. Your testers can also tell you the things they don't like, and make suggestions for improvements. Listen to them! Their advice is invaluable!